Telecommunications networks, such as the Internet, transmit data between various network entities such as a web server or an electronic messaging server via a common infrastructure. By way of example, the invention may apply to secure access from a network entity to a service platform.
The invention may also apply, by way of example, to transmitting an “original message” from a network entity to one or more other network entities; the term “original message” is used therein to mean any data set, e.g. electronic mail, or a request to initiate a voice-over Internet protocol (VoIP) call, or indeed an “instant message”. In general terms, an original message is sent by an “originating client” attached to an “originating” domain and connected to a “sending” domain, to a “destination client” attached to a “destination domain” and connected to a “receiving” domain (in the context of the present invention, an entity is said to be “attached” to a network domain when the entity possesses a service and/or a logical and/or an administrative link with the domain; for electronic mail, the logical address corresponds to the “email address”). The sending domain may optionally be distinct from the originating domain, and the receiving domain may optionally be distinct from the destination domain; this distinction between domains is useful, e.g. when a sending domain relays to a destination client a message sent by a roaming originating client who is connected to the sending domain but who is not attached to the sending domain.
As is well known, telecommunications networks are subjected to attacks aiming at professional, administrative, or individual targets. An attack that is nowadays commonplace consists in sending to as many destinations as possible messages that are undesirable in that they are not called for, such as “spam” for email or “spit” for Internet telephone calls. The term “undesirable” is used broadly and applies equally to the identity of the originator of the message, which may be authentic or falsified, and to the content of the message.
The potential for spam/spit type attacks relies in particular on the following factors:                the weakness of the protocols used on the Internet, such as the simple mail transfer protocol (SMTP) that is in the most widespread use for transferring email and that in particular does not incorporate functions for authenticating the sender of mail;        the increase in the power of computers that can send undesirable messages in bulk in automatic manner over a period that is very short; and        the increase in the number of networks that have access to the Internet and in the connectivity between those networks, thereby presenting a very large number of targets for attackers who can hide behind networks that are relatively lax or beyond the legal or administrative ambit of the target networks.        
Furthermore, it is not easy for a sending domain of the type “sender.fr” to determine whether an address of the type user@originator.fr supplied by a roaming originating client connected to the sending domain is valid, i.e. whether the client's address is indeed allocated in the domain “originator.fr”, and whether the client has the right to send a message from that address: the sending domain does not manage identities, i.e. the logical addresses of the type “originator.fr”. This difficulty of verification is often taken advantage of by attackers to send messages under a false identity from a domain to which attackers have access, or indeed via a corrupted machine situated in a legitimate domain. For example, an Internet domain “domain.fr” created by an attacker is entirely suitable for use in sending voice calls with a caller identity +332abcdefgh@domain.fr, even though the subscriber number “+332abcdefgh” is in fact allocated, say, to the domain “orange.fr”. Faced with an attack of this kind, requiring the calling domain to add a digital signature (cf. Internet engineering task force (IETF) document request for comments (RFC) 4474) is ineffective, since although it guarantees for the destination that the call does indeed come from “domain.fr”, it does not guarantee for the destination that the calling number is, in fact, registered in that domain.
One solution to this difficulty of checking consists in acting in the sending domain to block the sending of any message for which the originating address is not attached to the sending domain, however that solution is too limiting, in particular concerning the mobility of VoIP services that enable a roaming terminal to use a third-party relay such as a sending domain in order to set up a telephone call. This situation raises the problem of finding means that enable a destination domain to make sure that sufficient checks have been performed in the domain from which the message is being sent.
In the context of the present invention, the term “transaction” is used to cover all of the protocol exchanges that enable a shared secret or “primary session key” to be set up between two network entities A and B for the duration of a session. The transaction corresponds to the stage of initializing the session, which session may last for much longer than the transaction. In certain portions of the description, the terms “transaction” and “session” may be considered as being equivalent. For simplification purposes, the primary session key is also referred to as a “session key” between A and B, independently of any key-deriving or key-diversifying operations that may be applied thereto. The session key may for example be used to derive other secret keys for setting up a secure connection (transport layer security (TLS), Internet protocol security (IPSec), etc.) between the entities A and B. As another example, the session key may serve to guarantee the confidentiality or the integrity of an original message sent by the entity A (originating client) to the entity B (destination client); each new original message sent from an originating client to one or more destination clients corresponds to a new transaction; conversely, repeating a protocol step, e.g. as a result of a network problem, is not considered as a new transaction.
In principle, a network entity may naturally authenticate another network entity by means of a public key infrastructure (PKI). However, it is well known that PKIs are cumbersome to put into place and use.
In a variant, certain methods, such as the Diffie-Hellman algorithm, enable a session key to be determined in common by two entities prior to exchanging any original messages between them. However such an algorithm does not, in itself, give an entity A any guarantee about the identity of an entity B with which a session key is thus established.
In a variant, in networks having a small number of users, such as peer-to-peer networks, it is possible to provide for “manual” installation of a shared secret key for each pair of interested entities (e.g. by an on-site visit). However installing a shared secret key in this way is unsuitable for networks having a large number of users.
A solution that is well adapted to networks having a large number of users consists in setting up a trusted third party, commonly referred to as a “key distribution center”. Each network entity A seeking to make use of this secure communications service, takes out a subscription with the key distribution center, and consequently obtains, for a predetermined duration or for a predetermined transaction, a secret key KSA that is shared between A and an Authorization Server S associated with the key distribution center. Advantageously, the subscribers to this service do not need to store secrets or certificates relating to other subscribers, with communications being made secure on a transaction-by-transaction basis involving participation of the key distribution center. Furthermore, the key distribution center may, depending on requirements, transmit secret keys in secure manner to supporting entities (storage, gateways, etc.) that are under its control, or to legal entities in order to intercept certain communications. Since the key distribution center holds all of the secret keys of the subscribers, it is clearly essential for it to be powerfully protected against any hostile intrusion, however that does not represent any particular difficulty.
By way of example, one such method for secure communications between two entities A and B subscribing to a service is known under the name “Kerberos” (cf. IETF document RFC 4120). The Kerberos method essentially comprises the following steps:
1) an entity A identifies itself with an Authorization Server S and authenticates itself as the holder of an identifier IDA (after addressing itself to an authentication server that is distinct from the Authorization Server S); the Authorization Server S determines the secret key KSA that it shares with this entity A;
2) the entity A declares to the Authorization Server S its intention to communicate with a certain entity B; the Authorization Server S determines the secret key KSB that it shares with the entity B;
3) the Authorization Server S generates a session key KAB, and sends it to the entity A in encrypted form using said secret key KSA;
4) the Authorization Server S also generates a “ticket” T comprising at least said identifier IDA of the entity A and said session key KAB; the Authorization Server S sends the entity A check data CHECKA that is the result of encrypting said ticket T using said secret key KSB;
5) the entity A decrypts the session key KAB using its secret key KSA, and it sends to the entity B both the data CHECKA (that has been previously received by the entity A from the Authorization Server S), and also data δA that is the result of using the session key KAB to encrypt a set of elements comprising at least its own identifier IDA; and
6) the entity B decrypts the ticket T using its secret key KSB; the session key KAB then enables it to decrypt the identifier IDA of the entity A; the entity B verifies that this identifier is indeed the same as that contained in the ticket T; if the entity B approves the transaction, then it informs the entity A of this approval.
The entity A may then finish off the transaction with the entity B. For example, if the entity B is a supplier of services, the entity A may request some particular service and obtain it, by exchanging data with the entity B, which data is encrypted using the session key KAB. As another example, if the entity B is expecting a document from the entity A, then the entity A may send an original message to the entity B accompanying by the message authentication code (MAC) of the original message as obtained by means of the session key KAB (it should be recalled in this respect that in conventional manner, a MAC is a short value, generally occupying a few tens of bits, that is deduced from the data contained in a message and from a secret key shared between the sender and the receiver of the message by using a cryptographic algorithm; by sending a message accompanied by its authentication code, the sender enables the receiver to verify that the data does not come from any other entity and that it has not been tampered with between being sent and being received).
The Kerberos method thus provides for the session key to be transmitted firstly directly to the entity A and secondly indirectly (passing via the entity A) to the entity B; the entity B therefore has no need to communicate with the Authorization Server S in order to obtain the session key. The Kerberos method also makes it possible, advantageously, for the entity B to verify the identity of the entity A; this verification prevents a so-called “phishing” type attack in which an attacker identifies itself initially under its genuine identity with the Authorization Server S in order to obtain a transaction authorization from the server, and then under a usurped identity with the entity B (e.g. by passing itself off as the bank of the entity B in order to obtain confidential bank information).
Nevertheless, the Kerberos method presents the drawback that the entity B is still vulnerable to flooding attacks. On reconsidering step No. 6 above, it can be seen that before it is capable of identifying an attack, the entity B must perform two decrypting operations followed by an operation of verifying a match. Unfortunately, decrypting operations are expensive in terms of calculation time, such that an attacker can submerge the entity B by sending arbitrary data CHECKA and δA repeatedly to the entity B. Worse, an attacker may send to the entity B data CHECKA and δA that the attacker has previously read or intercepted during a transaction initiated by a legitimate entity A (replay attacks): under such circumstances, the attacker floods not only the entity B, but also the legitimate entity A, which receives confirmation messages from the entity B in repeated manner; version 5 of the Kerberos method does indeed protect legitimate entities A from flooding attacks by recommending that a time and date stamp be inserted in the data δA, however that further increases the burden on the entity B since it must verify that successive data items δA that it receives from a certain entity A all present different time stamps, thereby only worsening the flooding of the entity B.